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Electronic Certificate 

Field of the Invention 

5 The present invention relates to electronic certificates that pass on (delegate) an attribute 
from an issuo: to a subject and are signed by the issuer. 

As used hoein, the term "attribute" is used in a broad soise to include any c^abili^, 
characteristic or authorisation that can be associated with the subject, this usage being 
10 maintained even whoi discussing published documents that would tfiemselves place a 
more restricted meaning on die term. 

Furthermore, as regards to term "delegation" used herein to refer to the bestowing of an 
attribute by an issuer of a certificate to the subject named in the certificate, aldioughin the 

i 5 form of certificate discussed in detail below (SPKI certificate) the issuer has the right to 
exocise (as well as bestow) the attdbute concerned both before and after bestowal of the 
attribute on the issuer, this is not necessarily true for all forms of certificate to which the 
present invention can be applied. Accordingly, tfie term "delegation" should not be read as 
implying anything about the issuer's right, or lack of right, to exercise the attribute being 

20 bestowed on the subject. 

Background of the Invention 

By way of introduction, the general context and usage of SPKI certificates (whidi form 
part of the prior art) will first be described with reference to Figure 1-4 of the 
25 accompanying drawings. 

Figure 1 dq»icts a situation where a resource R has authorized party P, to use the resource - 
in effect, R has given access authorisation A to P,. P, can thus contact R and use its 
capabilities, R allowing access to P, upon P, establishing its identity. In addition, R has 
30 given P, the right to pass on ('delegate') the authorisation to others - in Figure 1, P, is 
shown as passing authorization A to party P4. When P4 contacts resource R, the latter will 
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require some proof that P4 has indeed been authorised by P, ; this proof takes the form of a 
certificate issued by P| to P4 and provided by P4 to IL In the electronic world this 
certificate will generally take die form of a digitally-signed document signed by P| using 
public-key / private-key cryptographic technology. 

5 

For present purposes, it will be assumed that the certificate Cj^ (and the other certificates 
refetred to below) are SPKI-like certificates, though it should be understood that this is not 
essential for the present invention. SPKI (^'Simple Public Key Infiastructure") certificates 
are described detail in references [2],[3],[4] listed at the end of this description. Figure 2 

10 illustrates the main elements of an SPKI-*like attribute certificate (as already noted, the 
term "attribute" is herein used broadly and in relation to SPKI certificates encompasses 
both ''authorization" and "attribute'* certificates as defined in the above-referenced 
documents). The Figure 2 certificate has fields for specifying the issuer of the certificate 
(ISSUER), the beneficiary of fiie certificate (SUBJECT^ tfie attribute being passed to Oie 

IS subjectbythecertificate(Al^lIORIZATIO^O>whetheronwa^ldelegat^onof&^ ^ 

is permitted (DELGATION), and the limits of validity of the certificate (VALIDITYy*An ^ 
important feature of SPKI-like certificates is that that they are primarily associated'vHth 
principals thai are public keys (or their hashes) rather than with parties identified by 
distinguished names. Thus, the **issuer" will always be aprincipal, that is» a public key or 

26 its hash); similarly the "subject" can either be a principal or, as will be seen later, a name 
that can be translated by a name certificate into a principal. Of course, there will be a 
keyholder who controls the private key associated with the public key forming a principal - 
however, it is not fundamental that the keyholder is named . 

25 In addition to the above-mentioned fields, certificate Ci^carries a digital signature formed 
by using the private key of the issuer. 

hi relation to the Figure t example, P| would be keyholder for a first key pair and P4 the 
k^holder for a second key pair, the ""issuer" of the certificate C,^then being the public 
30 key of the key pair associated with P^and the "subject" being the public key associated 
with P4. On receiving the certificate, R checks it by using the digital signature and public 
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key of the issuer. Since R will know the public key of P, and trust this knowledge (this 
would be part of the original authorisation of the P, by R). R can now be sure that the 
k^holder associated with the public key fonning Hhc subject of certificate C,^ has been 
duly authorised by P, . R can establish that the patty requesting access (P4) is (his keyholder 
by an ^propriate challenge-response transaction (in which P4 is required to use its private 
key to encrypt data sent by R, R then checking the returned encrypted data using the public 
key for which P4 is supposedly the keyholdo:). 

Figure 3 illustrates amore complicated situation in which P4 receives authorization A fitun 
P, not directly but ^ugh intermediate parties Pj and P,. This time P4 has the following 
cotificates: 

C,.2, - ttie certificate given by P, to P, to delegate authorisation A to P,; 
C2.3, - the certificate given by Pj to Pj to delegate autfiorisation A to Pjj 
C^4, - the certificate given by P j to to delegate authorisation A to P4. 
O f course, the parties P„ P,, P3 and P4 are not specified in the certificates directly, the 
latter refening to public keys Kroe.. Kfiw. Kpobj amd K^m respectively associated with P., 
Pj.P„andP4. 

P4 when requesting access to resource R passes the latter all three of the above certificates 
which R checks; R also checks that the party requestmg access (P4) is the key holder of 
pufaUckey K^. Thereafter, Rhasthe task of determining whether Kpu^ (P4>has indeed 
been delected authorisation A In other words, R needs to be able to establish a trusted 
chain of delegations of authorisation A from itself to K, ub4. The first link in fliis chain is, of 
course, the delegation by R to Ktobi and R does not require a certificate to prove this - it is 
a "trust assumption" of R R can then see from certificate C^tiiatKpuB, (PJ has authorised 
a principal constituted by public key Kp™, (PJ. From certificate C^,, R can also see tiiat 
Ktob2 bas in turn passed on the authorisation to K,obj (Pj); fauSLy, C,^shows that KpuBj has 
passed on authorisation A to KpuB4- By combining the certificates. R can establish the 
required bust chain from itself to K^^j^ (P4}. 



In carrying out the above proof, R will also have checked that the "delegation" field of 
each of the certificates C,.2 and C2.3 permitted onward delegation of authorisation A. 
Additionally, the validiQr fields of all tfiree certificates will have been checked 



5 It is possible that one party in the chain only delegated a subset of the authorisation A (for 
example, ordy some of the capabilities of R can be used by die subject of the certificate). R 
therefore needs to ascertain what is the scope of authorisation reaching K^^ba (PJ which is 
done by determining the intersection of the authorisation fields of all the certificates and 
seeing if this encompasses the requested access. 
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As noted above, the '^subject" of an SPKI-like certificate can be identified by aname rather 
than a principal; this name will be a local name referred to the name space in which it is 
defined (so as to provide a fiilly qualified SDSI name - see refCTences [3] and [6]). The 
name space identifier starts with the public key of the "issuer** req)onsible for the space 

15 within which the name exists (followed possibly by one or more sub-name spaces 
idCTtified by name). Where a local name occurs in the '^subject** of a certificate, the namei' 
space to which it refers is taken to be that of the "issuer" of the certificate. Naming a 
principal, if done, is primarily done for human convenience whilst SPKI processing 
systems fundamentally work with principals. The mapping between a name and the 

20 corresponding principal is done using a name certificate. Figure 3 depicts an SPKI name 
certificate and, as can be seen, the certificate has four fields that specify the principal who 
is the issuer of the certificate (ISSUER), the name being assigned in the name space of die 
issucr(NAME), the subject being named (SUBJECT), and the validity Imiits of the 
certificate (VALIDITY). The name certificate also carries a digital signature, formed 

25 using the private key associated with the issuer. 

In the most straigjbtfoiward case, the subject will be a principal so that the certificate maps 
a name in the issuer's name space to a corresponding public key (or its hash) - this is ttie 
case illustrated in Figure 3 where the local name "name" that forms the content of the field 
30 NAME is depicted as combining with the public key of the issuer Kp^j^ iggau map to the 
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public key KpuB^«, in the SUBJECT field. The subject may, however, alternatively be a 
fully qualified SDSI name. 

In determining whether a trust cbam exists, it may be necessary to use a name certificate to 
5 map an authorisation given to a named subject to the corresponding principal. 

A more formal considnation of die combining together of contents of certificates is given 
bi section 1 ofthe>^endix forming the final part ofthisdesaiption. In particular, section 
1, Appendix A treats both the delegation rule for combming 5-tuples fixmed by the 

10 contents of attribute certificates, and the naming mle for name mappmg using 4-taiples 
formed by the contents of name certificates. The tuple representations used m the 
Appendix and at other places in this description are of die form: 
5-tuple: <i.s.a,d,v> where i. s. a. d, v respectively correspond to the issuer, subject, 
authorisation, delegation and validity fields of an attribute certificate, and 

1$ 4-tuple: <i.n^s,v> where i. «. s. v correspond to issuer, name, subject and validity of a 
name cotificate. 

(It vrill be a^ipredated Aat the corresp<Hiding graphical rejxesentations of certificate 
contents in the accompanying drawings are less formal, for example die contents of an 
attribute certificate are generally shown as an arrow fiom the issuerto die subject, omitting 
20 the delegation and validity elements and, where required for clarity, also die aufliorisation 
element - which, if present, is placed alongside by the arrow). 

Proving a trust chain fiom the contents of certificates is relatively straight forward if tiie 
proving engine is presented with die correct certificates (or, rather, dieir contents) in die 

25 order required. However determining what cwtificates should be presented may not be a 
trivial task - it may be necessary to select die required certificates fi»m hundreds of 
available ones. The task of choosmg the certificates, sometimes referred to as "certificate 
path discovery", is discussed m die MTT Masters diesis of JeanrEn!ileEUen(reference[7]). 
A different form of discovery engine is described m Uiis specification and forms die 

30 subjectmatter.of our co-pending UK patent application, of the same date, entitled "Method 
and Apparatus for Discovering a Trust Chain Imparting a Required Attribute to a Subject". 
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The present invention relates to the following issue. It is not uncommon in everyday life 
that bestowal of an attribute is conditional upon some other attribute - for example, 
membership of a piofessional association will generally depend upon the subject having 
certain academic qualifications. However, in the electronic world a cotificates is genially 
S only issued onceany priorconditionsregardingtfaeattributetobepossessedby tfiesub^ 
have been proved to the satisfaction of the certificate issuK. This can significantly hamper 
the issuing of certificates but is generally accepted as it is seen as part of the value being 
added by the certificate issuing authority* 

10 It is an object of the present invention to provide an improved certificate infiastmcture 
easing the issuing of certificates and increasing their flexibility. 

SqiwiwarY of the Invention 

According to one aspect of the presmt invention^ there is provided an electronic certificate 
15 that has content data specifying an attribute delegation from an identified issuer to a 
certificate subject, and an electronic signature for confirming the content data; the content 
data including a condition requiring that a particular subject must have a particular attribute 
in order for the delegation to be valid. The said particular subject may be the same as or 
different fiom said certificate subject. The cotificale subject canbe specifically identified 
20 in the content data or may be unspecified ixiiereby the attribute is delegated to any subject 
capable of showing the certificate to be satisfied. More than one such subject-directed 
condition can be included in the certificate, the conditions bemg combined in a 
predetermined logical relationship. 

25 The present invention also contemplates me^ods and apparatus for generating and using 
such certificates. 

Of course, the standard VALTDITY field of prior art certificates is, in effect a condition 
carried by the certificate. By way of example, the VALIDITY field of an SPKI certificate 
30 will contain data about one or more of the following: 

- a date range identifying the period over which the certificate is valid; 



- the location of a certificate revocation list that should be checked before the certificate 
is used; 

- the location where a one-time use petmisi^dn can be obtained or the certificate re- 
validated. 

As can be seen, the VALIDITY field of an SPKI certificate acts as a condition directed at 
the validity of certificate itself and this is how it is generally perceived by persons skilled 
in the art The VALIDITY field does not define an attribute required of a particular 
subject. 
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Brief Description of the Drawings 

A certificate embodying the present inventioa anda trust cham discoveiy engine adapted to 
use such a certificate will now be described, by way of non-limiting example, with 
reference to the accompanying diagranomatic drawings, in which: 
. Figure 1 is a diagram depicting a simple authorisation delegation; 
is a diagram of an attribute certificate; 

is a diagram depicting an authorisation delegation chain and the role of 
cotificates in proving the chain; 
is a diagram of a luane certificate; 

is a diagram illustrating the form of a conditional certificate embodying the 
present invention; 

is a diagram of a trust-^faain discoveiy engine; 

is a diagram depicting a delegation chain forming ttie basis of a first 
example to be proved by the Figure 6 engine; 

is a table illustrating how the Figure 6 engine proves a trust chain for the 
first example; 

is a diagram depicting a delegation chain forming the basis of a second 
example to be proved by the Figure 6 engine; 

is a table illustrating how the Figure 6. engine proves a trust chain for the 
second example; 

is a diagram illustrating the incorporation of die Figure 6 engine in a 
resource subject of access requests; 



Figure 2 

• Figure 3 

. Figure 4 
. Figure 5 

» Figure 6 

• Figure 7 

« Figure 8 

• Figure 9 

. Figure 10 



30 . Figure 11 



8 

. Figure 12 is a diagram illustrating the incorporation of the Figure engine in a 
requesting entity; and 

. lilgure 13 is a diagram showing die course of processing by the Figure 6 engine 
vfhecc two of the certificates involved in goal proving are conditional 
S certificates of flu Figure 5 form. 

Best Mode of Carrying Oat the Invention 

Figure 5 shows a certificate embodying the present invention. The certificate is of the same 
general form as the attribute certificate shown in Figure 2 but now the VaUdity field 

10 inchides a subject-directed condition 40 in addition to the normal date/non- 
revocation/permission validity conditions placed on the certificate itself The condition 40 
could alternatively be included in a difTerent field or its own field. The condition 40 reads 
(DF "XYZ") which is interpreted to mean that some attribute "PQR" must be true in respect 
of the subject of the certificate before tiiat subject can be taken as having been delegatal 

1 5 the attribute specified in the Delegation field of the certificate.. Certificates including such 
subject-directed conditions are referred to below as 'conditional certificates'. 

More dian one subj ect-directed condition can be included in a conditional certificate, most 
readily with an (hnplied or explicit) AND relation^? between die conditions. Conditions 
20 may, however, also be linked by any other logical operator, though apart ftom AND, only 
the OR and NCW operators are likely to be of significant use (with regard to a negated 
condition, this of course means that the negative has to be positively proved). 

Conditional certificates can usefiilly be employed, for example, to localize a privilege. For 
25 example, an employee may only be authorised access to a particular resource from a given 
network subnet-this can be achieved by placingasubnet condition in the certificate giving 

resource access rights. The resource, in seeking to venfy that the employee has access 
authorisation, now needs to verify not only that the basic access authorisation attribute 
stems from a trusted source, but also that the employee has the specified subnet location 
30 based on trusted information. 
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For the Figure 5 certificate, the subject of the condition 40 was implicitly the same as the 
subject of the certificate as a whole. This could be the only possibility pennitted for a 
particular type of conditional certificate; however, it is also possible to require ttiat the 
subject of tiie condition must be explicitly declared, or to specify that if a subject is given 
S in the condition then this should ovenxile a default assumption that the subject of the 
condition is the same as the subject of the certificate. Where provision is made for the 
subject of the condition to be specified, then it becomes possible for the subject of the 
condition to be different to the subject identified in the SUBJECT field of die certificate. 

10 It is also possible to issue a conditional certificate with no subject identified in the 
SUBJECT field in which case the attribute associated with the certificate will be confored 
on any subject meeting the specified condition(s). 

It will be ^ipreciated that appropriate methods and apparatus for generating conditional 
15 cotificates are well within the competence of persons skilled in the relevant art. 

As will be more fully described hereinafter with reference to Figure 13, where a 
conditional certificate is involved in proving a trust relationship, the condition (or 
conditions) in the certificate efifectively gives rise to another trust relationship to be proved 

20 - in other words, it creates a branch in the trust chain being built. Provided the reduction 
engine being used to verify (he trust relationship is aware of Oiis possibility, branched tnist 
chains can be handled without undue complexity being added to the basic reduction 
engine. Thus, in one arrangement^ the justifying certificates are presented to the reduction 
engine in forward (or, indeed, reverse) order, starting with the main branch followed by 

25 each oth^ branch in turn. The reduction engine entity can then readily reduce the first set 
of certificates, using the delegation and naming rules, to establish the trust relationship 
represented by the main chain, noting on die way any conditional c^tificates and die 
required trust relationship they demand. The remaining certificates are then used to 
establish any such additional trust relationships. 

30 

As regards discovery engines for finding the set of certificates required to prove a trust 
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relationship, these can also be arranged to handle conditioaal certificates by recognizing 
that a new trust chain branch must be established for each condition attached to a 
certificate used in building the chain. This is tiue regardless of whether the discovery 
engine works forwards or backwards to prove the trust relationship. A discovery engine 
5 that performs a backwards proof and which is capable of handling conditional certificates 
will now be described^ starting with a desmption of how the trust engine operates in 
processing ordinary (non-conditional) certificates. 

Trust Chain Discovery Engine 

The trust-chain discovery engine SO illustrated in Figure 6 operates to seek to find a 
trust chain that starts vnUi a trusted issuer and ends with a specified subject SI , and 
delegates at least a particular attribute 52 to that subject. In seeking fiiis trust chain, the 
engine 50 uses axioms (trust assumptions) S3 that specify trusted issuer(s) and/or 
trusted delegation(s) involving a trusted issuer, and premises 54 fonned by the contents ^ 
(S-tuples and 4-tuples) of attribute and name c^ficates 55 which have been presented 
at some stage to the engine 50. These certificates are checked by a certificate verifier 
S7using for each certificate the acconq>anying signature and the public key of the 
issuer; although Figure 5 depicts the certificates as being checked when presented, this 
checking could, in fact, be left until after the certificate has been found to be involved 
in establishing a trust cimin of interest 

The trusted issuer may be a specifically idmtified principal or, more typically, the 
discovery method itself (labeled "SELF" below) - this latter possibility is usefiil as it 
enables principals that; are inherently trusted to be specified in the same format as the 
25 certificate-based premises with the issuer being SELF and the subject being the trusted 
principal (the attribute thus delegated then conesponding to the field over which the 
principal is triisted). This commonality of format fecilitates processing. Where the 
tmsted issuer involved in a delegation expression is SELF, this can conveniently be 
represented by a null issuer (though for clarity in the followmg description, the label 
30 "SELF" is retained). In the examples given in the following description, the trusted 
issuer is assiuned to be SELF for simplicity. 
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It vdll be appreciated that the engine SO can conveniently be implemented by 
appropriate programming of a general purpose computer and associated memory for 
storing, inter alia, the axioms, certificates and premises, and intermediate processing 
S results. 

la general the discovery engine operates by starting not with the first link in the trust 

chain (an axiom / trusted delegation) but with the desired conclusion which it then tries 

to justify by a backwards proof process applying reverse forms of die delegation and 
10 naming rules normally used for tuple reduction. Thus, a mam processing functional 

block 59 of the discoveiy engine starts with a functional block 60 that forms a primary 

goal to be proved in the fomi of a S-tuple: 

<SELF, Subject 5 1 , Required Attribute, true> 

where represents any valid value. In this respect, generally tbe state of the 
15 delegation element does not matter - which is not the case at all for intrntnediate 

delegations. 

Blocks 61 and 62 represent a recursive process of decomposmg a goal to be proved into 
subgoals which then become the focus of the goal proving process. A goal (subgoal) 
20 that does not have SELF as die specified issuer is considered proved if there is a 

matching premise whilst the subgoal including the issuer SEIP is considered proved if 
there is a matching axiom. 

Block 61 checks to see if the outstanding goal to be proved (alwaj^ arranged to be the 
25 goal including SELF as issuer) is proved by any of the axioms 53 - if it is, the primary 
goal has been proved and the chain of this axiom and the prooises proving the primary 
goal is retumed. However, if the goal containing is not matched by an axiom, block 62 
is entered. 

30 Block 62 seeks to decompose the outstanding goal into subgoals (usually just 

two).Subgoals are generated by using one of the certificate-derived premises (name or 
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attribute certificate) as one of the premises fonned by a reverse ^plication of the 
delegation or name nile. Thus, if the subject of the goal to be proved is "G" and the 
attribute concerned is ^'h", then the premises 54 are searched for a premise with subject 
also "G" and an attribute at least as CTibracing as V. If such a premise is found, then 

5 this premise forms one of the nevvr subgoals; the other new subgoal then has as its 

subject the issuer of the premise just found and used for the first new subgoal whilst tiie 
issuer of this second new subgoal is, of course, SELF. The attribute passed by the 
second subgoal is set to be the same as for the first new subgoal. The first new subgoal 
is justified immediately since it corresponds to a premise 54 and processing now 

10 returns to block 61 to check if the outstanding subgoal (the second newly created one) 
is proved by an axiom. 

It may not be possible to decompose a particular goal to be proved into any of the 
premises, in which case the current chain being explored is not valid. In this case, 

1 5 processing backtracks towards the primary goal until it reaches a subgoal that can be - 
decomposed by a different one of the prraiises to that previously used to decompose 
that subgoal. Assuming that such a re-decomposable subgoal exists, the processing 
continues in the manner already described. However, it may be that all possible 
decompositions have been tried without a complete chain back to SELF being 

20 discovered; in this case processing terminates with the primary goal unproved. 

During processing, a carefiil track is kept (block 63) of what has been tried and what 
has not (that is, which prenuses have been tried against which subgoals) and what 
premises cuuently make up the chain being explored- This is to enable the backtracking 
25 to proceed in a stmctured manner and to pemiit the premises making up a successful 
chain to be returned. 

It is conceivable that the proving process could loop which risks processing going on 
indefinitely. To avoid this, a subgoal list 64 is maintained of all subgoals created. Each 
30 time a new subgoal is generated it is compared with the list 64 and if it is found that the 
subgoal is already present, processing is temiinated. 
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Certificates (and thus premises 54) may contain validity conditions that are not easily 
discharged, such as time ranges or online checks. This makes it hard to check these 
conditions either before or during proof so in the Figure engine validity is only checked 
5 once a trust chain has been located, this being done during a forv^aid traversal of the 
chain. Of course, this means that an otherwise valid trust chain may have to be 
rejected. In this event, processing must be re-started to find another proof (there may be 
multiple proofi); to enable processing to continue where it left off» the state of the 
proving process at the time the first proof was found was stored in state memory 65. 

10 

The processing block 59, could alternatively be arranged to find all possible proofs at 
one go, these proofs being stored and one selected for validity testing, the other proofe 
not being used unless the first fails the validity check. 

15 Operation of the Pigure 6 engine will now be illustrated by two exan[q>les. The first 
example relates to the situation depicted in Figure 7. ResouiceR is set to allow access by 
Company X including by any employee of Company X provided they can prove this. 
Resource R trasts a principal I^iub.x matter related to Company X including its 

internal organisation (Divisions and employees); the principal KpuB^x ^ associated 

20 with a head-office server of Company X. Company X includes a Division Y that has a 
server which is associated vnfh a principal KpuB y. The attribute '"Division Y of Company 
X"* is bestowed on the principal K^^ y (the Division Y server) by BLp^B^x (the head-office 
server) through certificate Cx.y. In like manner a principal K^^^ z associated with an 
employee Z of Division Y is bestowed the attribute "Member of Division Y of Company 

25 X" by principal KpuB.y (Division Y server) through certificate Cy.z- 

Consider now what happens when employee Z wants to use resource R and establishes 
himself with R as the keyholder associated with Ktwz* Enqiloyee Z presents certificates 
Cx.Y and Cy.z to R and R now uses the trust chain discovery engme 50 to find a tmst chain 
30 authorizing employee Z to use resource R. Figure 8 depicts how the engine proceeds based 
on the target primary goal (issuer: SELF; subject: Kp^B^z)* premises derived fiom 
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certificates Cx.y and Cy^ and the axiom that K^ xCan be trusted for all things relating to 
Company . The discovery process proce«ls in two decomposition stages. The first 
decomposition generates a pair of subgoals: 

<SELF Ktob_y> and <Kpub.y ^nnj^ 
5 the second of which & justified by the premise based on Cy.2 . The second decomposition 

decomposes <SELF K^_y> into subgoals: 

<SELF -> KpuB.x> and <K^ji -> KpoB.v> 
the second of which is justified by the premise based on Cx.y whilst the first of which is 
justified by the axiom which trusts Kwax for all matters concerns Company X. 

10 

The second example is based on the situation depicted in Figure 9 which is similar to that 
of Figure 7 except that now the principal Kpus.y pivision Y server) bestows the attribute 
"Member of Division Y of Company X" on employee Z by using the employee's name 
"John Doe" as the subject of the certificate coacetned (Cy^ rather than the principal K^bje 
15 associated with employee Z. The name "John Doe" (or. more fully, Kpoey. "JohnDoe")is' 
associated with the principal Kroa.zby a name certificate The trust chain discovery 
process (see Figure 9) therefore involves a further stage of decomposition in order to 
translate the subject KroB^of the primary goal into the name "John Doe" (flus extrast^e is 
the first stage carried out). 

20 

In the foregoing, the issuer inherently tnisted by the discovery engine has been SELF 
where SELF is used merely as an intemal designation. In fact, SELF couldbe a principal 
capable of issuing certificates in which case a trost diain can be determined as found, not 
only in the case where tiie outstanding subgoal is matched by an axiom, but also where the 

25 outstanding subgoal is justified by a cotificate-based premise 54. Furthermore, as 
previously noted, the trusted issuer, rather than being SELF, could have been some 
specifically identified principal inherently tnisted by the discovery engine for matters 
including the attribute specified in the primary goal; in this case, the trust chain is 
detemuned to be complete when the outstanding subgoal including the trusted principal is 

30 justified by a certificate (that is, matched by a premise 54). Where there are multiple 
trusted principals and it is not possible to identify upfiont which will ground the trust 
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chain, the issuer of the primary goal can be specified generically (this coxild be by "a null 
issuer as with the representation of SELF); during the discovery process each new 
outstanding subgoal is then checked to see if it matches with apremise having as an issuer 
any of the trusted principals. It will he appreciated that this latt^ approach is generally less 
5 attractive than using SELF as the trusted issuo^ with axiooos corresponding to delegations 
from SELF to the principals to be trusted, as alreac^r described. 

Jn the foregoing examples, the engine 50 has been assumed to be associated with the 
resource R as depicted in general temis in Figure 1 1 - in other words, the requestor 

10 (employee Z in the examples) merely sends to R all the certificates that Z thinks might be 
useful in establishing the trust chain and it is up to the requestor to prove that such a chain 
exists. It would alternatively be possible to associate a discovery oigine with tiie requestor 
rather than the resource (see Figure 12X the requestor first detennining a relevant trust 
chain and ttien sending only the relevant certificates, in fbs correct order, to the resource; 

1 5 the resource then has a relatively simple task to reduce the certificates to prove that Ae 
requested is entitled to access. Of course, the requestor does not necessarily know the trust 
assumptions of resource R that can be used to ground a tmst chain; accordingly, the 
requestor must first notify its requirements to the resource which then responds with advice 
as to what trust assumptions might be of use to the requestor in determining ^propriate 

20 cotificates to send to the resource. 

It will be appreciated that the described tnist-chain discovery engine is not restricted to use 
with SPKI-like certificates since the 5- or 4-tuples used by the discovery engine are 
derivable from other forms of certificates as is explained and illustrated in section 6.5 of 
25 RFC2693 (see reference 3) 

The present engine uses Imear search to find premises generating subgoals. It is possible to 
index premises by subject to focus the search. This would reduce the amount of work 
considerably when the pronises set become large. 

30 

Processing of Conditional Certificates bv the Figure 6 Discovery Engine 
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The Figure 6 trust-chain discovery engine is also capable of handling certificates 
containing subject-directed conditions such as the attribute certificate shown in Figure S. 
Where the Figure 6 engine finds that the decomposition of a goal involves apiemise based 
on a certificate that contains a subject-directed conditional, it proceeds by introducing a 
S fiuther subgoal to be proved corresponding to the condition included in the certificate. Hie 
further subgoal is of the general form tihat SELF has delegated the attribute specified in the 
condition concerned to the subject of the certificate. The inclusion of a finther subgoal 
effectively branches the trust chain, both branches needing to be proved as will now be 
more fully described hereinafter with reference to Figure 13. 

10 

Where a conditional certificate includes multiple conditions in an AND relationship, then 
each condition gives rise to a new subgoal. However, if instead die conditions are linked by 
the OR operator, the engine 50 does not immediately generate a subgoal for each condition 
but starts by generating a subgoal for a first one of the conditions - only if the engine SO is "* 
1 S unable to generate a trust chain for tiie branch depending from that subgoal does it consido' 
the next condition by generating a corresponding subgoal which it then seeks to prove. 

Figure 13 depicts the course of processing effected by the Figure 6 engine in proving a 
primary goal 7 1 , here unspecified. In Figure 1 3 goals (including subgoals) to be proved are 
20 represented by circles with the decomposition of a goal bdng depicted by dependent lines 
connecting to two or more siAgoals. The subgoals chosm to fit certificate-basedpremises 
and therefore justified by those certificates are shown with a bar and the letter 'C below; 
where a subgoal is foimd as justified by an axiom (thereby grounding the trust chain) the 
subgoal is shown with a double bar and the letter 'A' below. 

25 

In the Figure 13 example processing, two single*condition conditional certificates are 
involved in justifying the trust chain giving rise to amain branch Bl for the trust chain and 
two side branches B2 and B3; branches Bl and B3 ground in respective axioms whereas 
branch B2 connects back into tiie main branch Bl. More particularly, goal 72 is 
30 decomposed into subgoals 73 and 74, subgoal 73 corresponding to a certificate-based 
premise; the certificate justifying subgoal 73 is a conditional certificate giving rise to a 
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further subgoal 75. At this point the trust chain being built splits into branches B 1 and B2, 
the branch including subgoal 74 being considered flie main branch. Similarly, 
deconq)Ositi(m of subgoal 74 is also based on a premise derived from a conditional 
certificate and gives rise to subgoals 77-79 where subgoal 79 is die based on the condition 
5 included in the certificate justifying the subgoal 77; a further branch B3 is thus formed off 
the main branch B 1 . 

The engine 50 pursues with proving one branch at a time, the tracker 63 being responsible 
for tracking what branches are to be proved and where the en^ne has reached in the 

10 proving process. In respect of the Figure 1 3 example, the engine 5 first proves brandiBl, 
fliis branch grounding in a first axiom. The engine then seeks to prove the branch B3 
(chosen because it was the last branch created). Branch B3 grounds in a second axiom. 
Finally, the engine seeks to prove branch B2. This branch is special in that it actually loops 
back into the main branch Bl - this results from decomposition of goal 83 generating a 

15 subgoal that is identical to subgoal 80 (or is encompassed by it). Engine 50 is arranged to 
spot this and to treat its proof of branch B2 as finished (die branch grounding to the first 
axiom through subgoals already forming part of branch B 1 of the trust chain. 

Example situations leading to branches in the trust chain are as follow. The primary goal 
20 to prove is that a principal (enq>loyee is an authorised buyer of dq>aitment Y of 
company X. The department Y is a purchasing dq;>artment but only those of its employees 
that have particular qualifications are entitled to fbs designation of authorised buyer. One 
way of handling this is to bestow tiie attribute "authorised buyer of department Y" on all 
employees (that is, their associated principals) using corresponding certificates but to make 
25 the certificates conditional on the subject having a specified qualification. The main 
branch in the trust chain relates to the delegation (with conditions not considered) of the 
authorised buyer attribute on X , this chain being for present purposes taken be, in the 
forward direction, SELF ■» X -> Y ->Z. The engine 50, wh«i decomposing the primary 
goal (SELF Z, authorised buyer attribute), uses the conditional certificate for employee 
30 Z and generates in addition to the usual two subgoals, a further subgoal corresponding to 
(SELF-> Z, specified qualification attribute). 
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The specified qualification could be one issued by a third party N for which company X is 
not treated by the axioms of engine 50 as being tnisted to prove; instead, engine SO holds 
an axiom that party N is to be trusted in respect of all qoaUfications issued by it. In this 
S case, the trust chain branch relating to the qualification can be grounded in the axiom 
relating to party N. This coxiesponds to the situation represented by branch B3 in Figure 
13. 

Alternatively, the specified qualifcation could be one issued by the training section TS of 
10 department Y of company X; in fliis case, the qualification branch of the trust chain has a 
subgoal (SELF -» TS ) which, assuming that a certificate (Y -^TS) has been presented, 
decomposes into (SELF ^ Y) and CY-> TS). The latter subgoal is justified by the certicate 
whilst the fonner corresponds to a subgoal that is already part of &e main brandi. This 
corresponds to the situation represented by branch B2 in Figure 13. 

IS 

With regard to the loop check previously described (where engine 50 is arranged to check 
for duplicate subgoals by comparing each newly generated subgoal with tiiose already in 
the subgoal list 64, and to tenninate processing if the subgoal is already present), this 
check is refined for handling branches resulting fiom conffitional cotificates. More 
20 particularly, processing is not terminated if a newly-generated subgoal present in one 
branch matches with a listed subgoal in another branch - this will generally indicate that 
the branch being explored has merged back into another branch that has already been 
proved. 

25 With respect to the forward traversal of the trust chain carried by engme 50 to check the 
validity of the chain with respect to the normal validity conditions (date/non- 
revocation/petmission), where the trust chain involves branches, then the forward traversal 
is done branch by branch, starting with the main branch (the branched structure of the trust 
chain having been returned by block 61 along with the list of subgoals proving the chan). 
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Appendix 

This Appendix forms an integral part of the preceding description and of the specification 
as a whole. 



5 1, Certificate Inference Rules 

SPKI certificates and the s-exp syntax are desoibed in references [2, 3» 4, 6]. SPKI defines 
two inference rules for certificates* a delegation rule and a name-rewriting rule. The 
delegation rule combines two cotificates, one issued by A to B and one issued by B to C to 
give a third certificate issued by A to C. The name-rewriting rule allows the subject name 
10 of a certificate to be rewritten using a name certificate. The SPKI definition is relatively 
informal, and we formalize it below. 

In defining the certificate inferrace rules we follow file SPKI convention of 
representing the contents of a certificate by a 5-iuple with the following fields: 
IS • issuer i: Public key (or its ha^) of fiie certificate issuer. 

• subject 5 : Identifies who or what the capability is issued to. A public key, key 
hash or object hash (or a name for one). 

• authorisation a: The attributes (capabilities, authorisations, or other 
characteristics) transfexred firom the issuer to the subject by this certificate. 

20 • delegation d: Boolean, if this is true the subject is allowed to delegate 
capabilities. 

• validity v: A collection of conditions which must all be true for the certificate to 
be valid. 

25 We use the following notation for a S-tuple: 

<i,s,a,d,v> 
where s, a,d,vm the certificate parameters above. 
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We use the following notation for a name certificate: 
with fields 
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• issuer i: Public key of the certificate issuer* 

• name n: Name being defined. 

• subject $: Name or principal the name is defined as. 

• validity v: Conditions which must be true for the certificate to be valid. 

5 

We present goals in die form of sequents: 

Here F is a list of certificates, the assumptions or premises, while A is the resulting 
cerdficate. the conclusion. The symbol h is called turnstile and is pronounced entails. The 
10 inference rules are presented as a sequent calculus [S]. 

This is the certiflcate delegation rule: 

15 

This means that if the sequents above the line can be proved the sequent below the line 
follows. Here a^r^^ is authorisation intersection and ViOv, is validity intersection. 

The rale requires that the subject of the first certificate, s^ . is equal to the issuer of the 
20 second certificate. It is possible for a subject to be a hash as well as an explicit principal, 
and we consider a hash equal to a principal if the principal's hash is equal to it 

The name certificate rule is 

r K to, tn.y, a,d,vi> Ah [i.n = 3| vt] 
25 r U A H< io, 3.», a, d, vi n V2 > 

Here we use Ln for a name starting with i. So the rule says that a name with a prefix 
matching the definition can be rewritten by replacing the prefix with the value. 

30 Assumption rule: 

T.AhA 

A A 



Adding 



to a set of assiimptions proves 
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Weakening rule: 

rh< S(i,suaudi,vi > 

rh< S(i,Sua2,d2,V2 > 

as long as Oji V2 are respectively weaker than a„ e/,, V| . For tags a, is weaker than a, iff 
(if and only if) — ajOaj . For delegation flags dj is weaker than di as long as 4z is not 
true when is false* For validities is weaker than V| iff = ViOv, » 



Tag matching rules 

The authorisation field (or tag) in a certificate can contain attribute/authorisation patterns 
as well as explicit authorisation. Also an explicit tag is compatible with any longer tag. 
IS Tags have to be intersected as part of the verification process, and we define the tag 
intersection rules here. Abstractly we consider a tag as defining a set of objects matching it 
Tag intersection is then set intersection, where the resulting set must be expressed using 
tags. 

20 We define tag intersection as follows. Tag intosection is commutative, so a rule for x 
intersect y also applies to y intersect x. We always use flie most specific rale. Any cases 
not covered are defined not to intersect. 

• atom x — atom y: intersect if they are equal. The result is x. 

• list X - list y: intersect if a prefix of one has elements that intersect the 
25 corresponding elements of the odier. The result is the list of prefix intersections 

appended to the remainder of the long^ list If ttiere is no intersecting prefix they 
do not intersect. 

• star - y : always intersects, with result y . 

• set X - y: intersect if there is some element of x that y intersects. The result is the 
30 set of all intersections of elements of x with y. If the result has one element it is 

returned instead of a set. 

• set X - set y: intersect if there is some element of x that intosects some element of 
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y. The result is the set of intersections of elements of x withy. If the result has one 
elonent it is returned instead of a set 

• range x - atom y: intersect if y lies in the defined range. The result is y. 

• range x - range y : intersect if they have the same ordering type and a non-empty 
5 intersection range exists. The resutt is the biggest range that is compatible with 

themboA. 

• prefix X - atom y: intersect if y has die given prefix. The result is y. 

• prefix X- prefix y: intersect iftheir prefixes are compatible. The result is a prefix 

tag with the longer of the two prefixes. 

10 

Here, tags are defined not to intersect in some cases where the semantics intersect. 
Consider range-prefix intersection for exanq^le. This is defined to Ml, but could be 
computed. The set tag is essentiaUy a logical or of tag patterns. It might be useful to 
consider adding a logical anrfof tag patterns. This would make itshnpleto define arbitrary 
15 tag intersection: in the absence of a specific mle it would be the logical and of the tags. 

Tags are equal if they have the same type and equal parameters, except for set tags. A set 
tag X is a subset of set tag y if every member of x is equal to a member of y. A set tag x is 
equal toasettagyifxisa subset of y and y is a subset of x. EquaUty of set tags is 
20 indepoident of the order of their elemoits, 

Semantically tags are the same if they express the same sets. The tag eqtiality rule attempts 
to reduce this to syntactic tests on the tags. This means that tag equaUty fiuls in some cases 
where semantics are equal. It may be worth considering working out a complete tag 
25 eqwaUty mle based on the semantics. If a normal form exists we can reduce tag equaUty to 
equaKlyof noiroal forms. If anonnal form does not exist we require a satisfiabiUty checker 
for the tag logic and this may be provided using a predicate tableau [1]. 

30 2. Backwards proof 

Inference rules naturally suggest forwards proot working fiom hypotheses to 
conclusions. However, here we do backwards proofby using them in the reverse direction 
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to decompose a goal into subgoals. We use the theorem-proving technique of backwards 
proof to derive the sequence [S] though we need to modify the rales to make this work. 
Consider the delegation rule. Working backwards we pick 0| and equal to Ae tag in the 
goal, and use the same assumptions. We treat the oth« fields similarly. 

5 

rH< s^,si,a^T,t; > rh< Sus%ya^d^v> 

where the rule is now to be interpreted in the reverse direction^ telling us how to construct 
subgoals from the goal. 

10 

The name certificate rule is modified similarly: 

r \r<i^,i.n,y^a^dyV > rh[i.n = s,v] 

We can use a thinning rule to drop assumptions: 
This gives us a more general assumption rale: 

M^th regard to constracting a prooJ^ running the delegation rule or name certificate rule 
20 backwards would q>pear to produce two subgoals. However, if we always choose the 
second subgoal to be one of our assumptions we can discharge it immediately^ leaving one 
subgoal. Given a goal we iterate through the assumptions looking for certificates that allow 
us to use one of the reverse rules. When we find a suitable name certificate we rewrite flie 
subject using the inverse of the name definition and try that subgoal. 

25 

We examine certificates to see if they are suitable as the second premise in the delegation 
rule. They must have the same subject as the goal and authorize what it does. In practice 
we combine this with ttie weakening rale and accq>t certificates that authorize at least as 
much as the goal. It is convenient to ignore the goal^s validity conditions at this stage as 
30 they can be handled later by a forward proof traverse. The first premise of the rule 
becomes the subgoal. If proof of a subgoai fails we resume the iteration through the 
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assumptions looking for suitable certificates. If this backtracking runs out of alternatives 
the proof asawhole has failed. If theproof succeeds wereturn the last subgoal and the list 

of certificates that lead us to it We then traverse this list constructing the forwards proof to 
gel the final conclusion. Wecheckfliat the authorisation of the origM goal is 

the authorisation of the conclusion of the proot but we allow the vaUdity to be different, 
niis is becausb we only know we want the vaUdity to evaluate to tiue. but we do not know 

what vaUdity conditions certificates wiU impose, and we may not be able to check 
them during proof (since they may include online checks). The vaUdity must be checked 
before the authorisation is enacted. 
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TerminatioD and completeness 

It is possible to constmct sets of name certificates such fliat forwards rewriting does not 
terminate. Asimpleexampleis[i.tt = i.a.al. However, backwards prooftenninates even in 
the presence of this defmition since it can never make a name longer. It is still possible for- 
1 5 backwards proof to loop however. This happens if a sequence of rewrites creates the same 
subgoal again. The name certificates [i.a = i.b\ and[Lb^La} fijimsuchacycle (which also 
loops forwards). Looping can also occur because of delegation cycles. 

We prevent looping by keeping a stack of subgoals and checking whether a subgoal 
20 already exists before adding it This also causes termination, since in order for the trust- 
chain discovery engine to fail to tenninate tt has to generate an infinite sequence of 
different subgoals. This is because an infinite tree witii finite branching must contain an 
infinite branch. However our certificate seta are finite so there is no infinite derivation 
using them (as long as we work backwards). 

25 

It can also be shown that the backwards algoritiun finds a derivation if one exists. Suppose 
aderivation exists. Itmust start withatnist assumption, usenamecertificates or delegation 

certificates and end with the desired goal At each point in this derivation we have a goal 
withacwtificatejustifying its derivation ftomanotiier certificate. Tlie algorithm consid^ 

30 all possible candidates for such steps, so it must find them if they exist The algorithm 
backtracks over all possible steps, so it must find the derivation if it exists. Combining this 
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with the termination property above we see that the algorithm is complete (finds a 
derivation if one exists) and terminates. This means it is a decision procedure for goals. 



Trust assumptions 

So far the trust assiunptions have not been motioned. We represent a trust assumption as a 
5-tuple with a null issuer. Since null issuers are illegal in certificates they can arise in no 
other way. When a trust-chain discovery engine creates the initial goal it sets the issuer to 
null. This means that only proofs starting from the tnist assumptions will he accepted. The 
proof process does not need to treat trust assumptions specially. 

3. Extension 

Sequent calculi normally contain logical rules in addition to the structural rules we have 
defined. These can be used to represent intermediate deductions, such as the cut rule 

This allows a proof to be structured into lemmas, and provides a formal basis for storing 
previously proved theorems and using them in proofs. 

At present the described trust-chain discoveiy engine only supports proving a single tag, 
20 with a set of tags treated as having to prove them all. This is a restricted form of logical 
and. It is possible to extend the calculus by explicitly introducing logical connectives, such 
as and and or, togettier with their inference rules. This would allow us to tieat proofs of 
('^'set) patterns more flexibly than at present 

25 
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CLAIMS 

1. An electronic certificate that has content data specifying an attribute delegation from an 
S identified issuer to a certificate subject, and an electronic signature for confirming the 

content data; the content data including a condition requiring that apaiticular subject must 
have a particular attribute in order for the delegation to be valid. 

2. A certificate according to claim 1, wherein said certificate subject is generically any 
10 subject whereby said attribute is delegated to any subject enable of showing said 

condition to be satisfied, the particular subject of said condition being explicitly idmtified 
in the content data. 

3. A certificate according to claim 1, wherein said certificate subject is specifically 
1 5 identified in the content data. 

4. A certificate according to claim 3, wherein said particular subject is not separately 
specified but is implicitly said specifically-identified certificate subject 

20 . S. A certificate according to claim 3, wherein said particular subject isexplicitly identified. 

6. A certificate according to claim 1, including multiple said conditions in predetermined 
logical relationship. 

25 7. A certificate according to claim 6, wherein said logical relationship is explicitly stated. 

8. A certificate according to claim 6, wherein said logical relationship is not explicit but is 
implicitly an AND relationship. 

30 9* A certificate according to claim 1 or claim 6, wherein said content data includes 
certificate validity conceming at least one of: 
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- a date range identifying the period over which the certificate is valid; 

- thelocationofaceitificaterevocatioaKstthatshouldbecheckedbefotcthecertificate 

is used; 

- the location where a one-time use pomission can be obtained or the certificate re- 
5 validated; 

said content data being structured into fields with the validity data and said condition or 
conditions being held in the same field. 

10. A certificate according to any one of the preceding claims wherein the certificate has 
10 substantially thesameformasanSPKIcertificatewithsaidconditionorconditionsbeing 

held in the validity field of die certificate. 

1 1. Apparatus for generating a certificate of the form set out in any one of the preceding 
claims. 

15 

12. A reduction engine for combining certificates to estabKsh a trust chain, at least 
comprising attribute delegations justified by certificates, that overall imparts a required - 
attribute ftom a trusted issuer to a target subject, said reduction engine being operative 
upon usingaccrtificateaccording to any oneof claims 1 to 10 fprjustifying a delegation, 

20 toestablishabranchofsaidtnistchainpassingbetweensaidconditionandatnistedissuer. 

13. A trust chain discovery engine for finding a trust chain, at least comprising attribute 
delegations justified by certificates, that overall imparts a required attribute firom atrusted 
issuer to a target subject, said reduction engine being operative upon using a certificate 

25 according to any one of claims I to 10 for justifying a delegation, to establish a branch of 
said trust chain passing between said condition and a trusted issuer. 
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